Draft PR of the current state of the sensor abstraction layer and hardware setup file. It will definitely be split up when time comes.

Current implementation:

• the await_read_sensor_main! function-like proc-macro reads the list of sensor concrete types from hw-setup.yml
• the _await_read_sensor_main! declarative macro downcasts the sensor trait object to a concrete type, reads the "main" sensor value and awaits it (required because different opaque types otherwise)
• riot_rs::hw_setup attribute macro populate the sensors application modules with sensor driver instantiation and initialization (to be completed)
• handles a homogeneous interface when iterating over sensors, and a specific interface when accessing a sensor directly by its global name

Major pieces which are currently missing:

• Sensor categories: we should have sub-traits of the Sensor trait for each sensor categories (e.g., temperature sensors, accelerometers, …) so that it is easy to replace a sensor with another one from the same category
• Consistence sensor initialization, generated from the hardware setup file
• Sensor configuration (refresh rate, mode selection, I2C address, …) from the hardware setup file

Points of interests:

• The Sensor trait has two "read" methods:
  • a Sensor::read_main() (which needs a better name), which provides a consistent interface across all categories of sensors (and thus only returns the "main" value returned by the sensor) and should return an enum to allow for multi-dimensional tuples, and
  • a Sensor::read() method, which returns a type implementing Reading, allowing each sensor to return a custom type (this should change when introducing sensor categories).